3. Edge Transport Configurations
This section describes Edge Transport configurations that you should consider when planning for this server role: cloned configuration, delivery status notifications, header firewall, and address rewriting.
3.1. Edge Transport Cloned Configuration
Cloned configuration is the process of configuring multiple Edge Transport servers with identical configurations.
You can use the cloned configuration scripts provided as part of the
Exchange installation kit with EMS to duplicate the configuration of a
source server to a target server.
Edge Transport servers do not support Windows
Failover Clustering. A failover cluster provides high availability by
making application software and data available on several servers that
are linked together in a cluster configuration. But because failover
clustering is not available, to achieve high availability for messaging
transport, you should implement multiple Edge Transport servers.
Note: Even
though AD LDS supports directory replication, Exchange Server 2010 does
not provide an option to use directory replication for configuring
multiple Edge Transport servers. The only
way to copy the configuration between the Edge Transport servers is to
use cloned configuration. This needs to be done whenever you do any
configuration changes to one of the servers.
You can use
cloned configuration to ensure that all the Edge Transport servers have
the same configuration. You only configure one server, and export the
configuration to an XML file that is then imported to the target
servers.
The XML file includes the following configuration information:
Transport server file paths and all log files paths (such as the Message Tracking log path)
Transport agents, including status and priority
All Send and Receive connector–related settings (including Send connector passwords encrypted with a default encryption key)
Accepted Domain information
Anti-spam features and configuration settings
Note: Don't
forget that any Transport Rule configured on the Edge Transport server
is not exported, so you need to export the rules with the Export-TransportRuleCollection cmdlet and import them on the target Edge Transport servers.
Some settings are not
cloned; however, they are synchronized by EdgeSync and therefore only
need to be considered in a configuration where EdgeSync is not used:
To configure cloned configuration, use the ExportEdgeConfig.ps1 and ImportEdgeConfig .ps1 scripts located in the <Exchange_Install_Path>\Scripts
folder to export configuration information from one Edge Transport
server to an identically configured Edge Transport server. You can also
use the tool to test configuration changes and offer rollback
assistance or to assist in disaster recovery when you deploy a new Edge Transport server or replace a failed server.
To configure cloned configuration, follow these steps:
Use the ExportEdgeConfig.ps1 script to export the configuration information on the source Edge Transport server.
Validate configuration and create an answer file using the ImportEdgeConfig.ps1
script on the target Edge Transport server. The answer file will
contain entries for every source server setting that is not valid for
the target server.
Edit answer file and change all server-specific settings, such as the server name, to reflect the target server settings.
Import
configuration using the ImportEdgeConfig.ps1 script with the -IsImport
$true parameter to import the information from both the intermediate
XML file and the answer file on the target Edge Transport server.
Note: When
importing the configuration, depending if the target Edge Transport
configuration is part of Edge Synchronization or not, you may face
error messages that some settings, such as Accepted Domains, cannot be
imported. This situation is normal and can be ignored.
Delete the configuration and answer XML files to prevent retrieval of Send Connector passwords (if used).
3.2. Understanding Header Firewall
Every Receive or Send
connector adds information to the message it is transferring. This
information is available in the SMTP message header and includes
information such as all the servers that transferred that message and
at what time. To prevent spoofing of such information, Exchange 2010 includes a feature called Header Firewall
that (if configured) removes all additional information from inbound
and outbound messages. But let's first start with an overview of the
X-header fields.
3.2.1. Overview of Exchange 2010 X-Headers
Exchange Server 2010 adds
X-header fields to every message to transfer Exchange-internal
information. X-header fields are an unofficial but generally accepted
way to add header fields to a message.
The purpose of X-header
fields is to transfer information about the message to the other
Transport servers. For example, a message is scanned by the Content Filter agent only at the first Transport server, which adds the spam confidence level (SCL) rating to the X-MS-Exchange-Organization-SCL field to the header of the message. All subsequent Transport servers can then use this information and do not need to scan the message again. In Figure 4 you see a message that contains various X-header fields by looking at the Internet headers field in Microsoft Outlook.
To read the message
headers correctly, it is important to understand their meaning.
Exchange Server 2010 includes several X-header fields and they are
listed in Table 2.
Table 2. X-Header Fields Used by Exchange 2010
| X-HEADER FIELD | DESCRIPTION |
|---|
| X-MS-Exchange-Forest-RulesExecuted | Lists all transport rules that processed this message. |
| X-MS-Exchange-Organization-Antispam-Report | Provides a summary report of the anti-spam filter results that have been applied to the message by the Content Filter agent. Detailed information can be found on TechNet "Understanding Anti-Spam Stamps" at http://technet.microsoft.com/en-us/library/aa996878.aspx. |
| X-MS-Exchange-Organization-AuthAs | Specifies the authentication source. The possible values are Anonymous, Internal, External, or Partner. |
| X-MS-Exchange-Organization-AuthDomain | This
field is only added when Domain Secure authentication took place and
includes the fully qualified domain name (FQDN) of the remote
authenticated domain. |
| X-MS-Exchange-Organization-AuthMechanism | Specifies the authentication mechanism for the submission of the message as a two-digit hexadecimal number. |
| X-MS-Exchange-Organization-AuthSource | Specifies the FQDN of the server computer that evaluated the authentication of the message on behalf of the organization. |
| X-MS-Exchange-Organization-Journal-Report | Identifies journal reports in transport. |
| X-MS-Exchange-Organization-OriginalArrivalTime | Identifies the time when the message first entered the Exchange organization. |
| X-MS-Exchange-Organization-Original-Sender | Includes the original sender of a quarantined message. |
| X-MS-Exchange-Organization-OriginalSize | Includes the original size of a quarantined message. |
| X-MS-Exchange-Organization-Original-SCL | Includes the original SCL of a quarantined message. |
| X-MS-Exchange- Organization-PCL | Identifies the phishing confidence level. The possible phishing confidence level values are 1 through 8. |
| X-MS-Exchange-Organization-Quarantine | Indicates that the message has been quarantined in the spam
quarantine mailbox and a delivery status notification (DSN) has been
sent. Alternatively, it indicates that the message was quarantined and
released by the administrator. |
| X-MS-Exchange- Organization-SCL | Includes
the SCL of the message. The possible SCL values are 0 through 9. A
larger value indicates a suspicious message. The special value -1 means
that it is an internal message that is not processed by the Content
Filter agent. |
| X-MS-Exchange-Organization-SenderIdResult | Includes the results of the Sender ID agent. The Sender ID agent uses the sender policy framework (SPF) to compare the message's source IP address to the domain used in the sender's e-mail address. |
| X-MS-Exchange- Organization-PRD | Includes the result of the Sender ID agent, especially the Purported
Responsible Domain (PRD). This is the domain of the purported
responsible address as determined by the Sender ID agent. |
Besides X-header fields, Header Firewall also controls Routing headers. Routing headers include information about all messaging servers used to deliver the message.
3.2.2. Configuring Header Firewall
In some situations you need to implement Header Firewall to prevent someone from creating a message that will spoof X-headers
and thereby imitate an Exchange Transport server in order to have their
messages accepted as legitimate by the receiving server. This is
especially crucial if your organization does not include a smart host
that removes these headers.
Header
Firewalls are configured by assigning Active Directory permissions on
the respective Send connector or Receive connector. A dedicated ExtendedRightDeny permission is used to control enabling or disabling a Header Firewall. The following principle applies: attribute and
If Deny is enabled (or True), the Header Firewall is turned on for the specified area and headers are removed.
If Deny is disabled (or False), the Header Firewall is turned off and the headers are preserved by the connector.
By default, no Send or Receive connector is configured for Header Firewall. In a situation where you use an Edge Transport server, the X-header is overwritten anyway when a message enters the organization. But for outbound
messages, Routing headers might disclose too much information about
your company. For example, the name of any internal Hub Transport
server that processes the message is shown in the Routing header.
Several Extended Rights control Header Firewalls on Send connectors and Receive connectors. Table 3 provides an overview of possible Extended Rights.
Table 3. Connectors and Extended Rights for X-Header Configuration
| CONNECTOR | EXTENDED RIGHT | DESCRIPTION |
|---|
| Receive connector | ms-Exch-Accept-Headers-Forest | Configures Header Firewall on "X-MS-Exchange-Forest …" headers |
| ms-Exch-Accept-Headers-Organization | Configures Header Firewall on "X-MS-Exchange-Organization …" headers |
| Ms-Exch-Accept-Headers-Routing | Configures Header Firewall on "Resent- …" and "Received:" headers |
| Send connector | Ms-Exch-Send-Headers-Forest | Configures Header Firewall on "X-MS-Exchange-Forest …" headers |
| Ms-Exch-Send-Headers-Organization | Configures Header Firewall on "X-MS-Exchange-Organization …" headers |
| Ms-Exch-Send-Headers-Routing | Configures Header Firewall on "Resent- …" and "Received:" headers |
To configure Header
Firewalls, you can either use EMS or directly access the Permissions
tab of the connector's Advanced Security Settings using ADSIEdit, as shown in Figure 5. You can see Advanced Security Settings of the Send connector on the Edge Transport server that connects to the Internet. Because Deny is set for Anonymous Logon on Send Routing Headers permission, all internal message servers are removed from the routing path.
When using ADSIEdit in Active Directory to configure permissions, remember that you can configure Edge Transport Receive connectors only directly on the Edge Transport server. Thus you can only configure Send
connectors using ADSIEdit in Active Directory, for configuring Edge
Transport Receive connectors you need to use EMS on the Edge Transport
directly, as Receive connectors are not synchronized to Active
Directory with EdgeSync.
Configuring Header Firewall using EMS is not trivial—many groups
are involved and you have to configure the right group to turn Header
Firewall on or off. The best approach is to look at your existing
connectors to identify the groups you need to configure. The following
cmdlet is an example to show you the Extended Rights of a Receive
connector:
Get-ReceiveConnector <ReceiveConnectorName> | Get-ADPermission | ft user, deny,
ExtendedRights
To configure Header
Firewall in your scenario you just need to change the permissions on
the respective Receive or Send connector. For example, let's turn on
Header Firewall for Routing
headers on the Send connector to the Internet for all non-authenticated
target servers. You can configure this using the following cmdlet on
the Send connector that sends messages to the Internet:
Add-ADPermission -id "<SendConnectorName>" -User "NT Authority\Anonymous
Logon" -ExtendedRights Ms-Exch-Send-Headers-Routing -Deny
Remember that after you configure the permissions,
you need to restart the Microsoft Exchange Transport service on all Hub
Transport servers that are configured to use the Send connector so that Header Firewall will take immediate effect.
You can verify whether Header Firewall is turned on by enabling verbose logging on the Receive connector in EMC or using the ProtocolLoggingLevel VerboseSet-ReceiveConnector cmdlet. You will now receive a detailed protocol log in the <Exchange_Install_Path>\TransportRoles\Logs\ProtocolLog\SMTPReceive
folder. In the current log file, you will find the following entries
for each SMTP session that has Header Firewall turned off: parameter in the
For every entry that's missing, Header Firewall is enabled!
|
Christian Schindler
Senior Consultant, NTx BackOffice Consulting Group, Austria
One of my customers once had an issue where inbound mail delivery from Edge Transport to Hub Transport was working correctly, but anti-spam—although correctly configured—didn't work as expected: X-AntiSpam- and Antivirus-Headers (SCL, SenderID, and so on) weren't part of the message header when the message reached Outlook.
After digging into the
issue, I finally discovered that authentication methods between the
Edge and Hub Transport server were modified from the default settings.
I re-enabled Exchange Server authentication on the connectors, which
fixed the issue.
So why is authentication
between Edge and Hub Transport important in my scenario? Because
Exchange only accepts X-AntiSpam- and AntiVirus-Headers through
authenticated SMTP Sessions. This makes it nearly impossible for
spammers or hackers to send fake X-AntiSpam or X-Antivirus Headers.
|
3.2.3. Header Firewall for Contoso Scenario
For most scenarios, especially
if you use Edge Transport servers, you do not need to change Header
Firewall settings—their default configuration is sufficient for most
scenarios. However, if you do not use Edge Transport servers, you
should enable Header Firewall for the Receive connector and Send
connector to the Internet.
In the Contoso scenario, the Hub Transport server receives messages from a smart host from the Internet. To prevent spoofing of X-headers it is best practice to configure your Receive connector that receives the messages from the Internet to enable Header Firewall. This is done using the following cmdlet:
Add-ADPermission -id <ReceiveConnectorName> -User "NT Authority\Anonymous Logon"
-ExtendedRights ms-Exch-Accept-Headers-Organization -Deny
Figure 6
shows you the header configuration as performed through EMS for
X-headers Organization and the command to verify that the permission
was configured correctly. As seen in the figure, only the
ms-Exch-Accept-Headers-Organization has a Deny permission configured;
thus only this X-header has Header Firewall turned on.
3.3. Configure Address Rewriting
Edge Transport servers include Transport agents that allow you to modify e-mail addresses for inbound or outbound messages. This process is called address rewriting.
Two Transport agents
provide the capability for address rewriting: Address Rewriting Inbound
agent and Address Rewriting Outbound agent. They should be enabled for
address rewriting to work correctly.
But why do address rewriting? You need to implement it for several reasons, including the following:
Group consolidation or Partners
This is when your company includes several groups that have separate
e-mail addresses internally. For example, you have a group that uses
the e-mail address @sales.contoso.com but your company wants to move to
a single e-mail address and thus replace all messages with the
originator of @sales .contoso.com with @contoso.com.
Mergers and acquisitions
This situation occurs when your company purchases a new company that is
running in a separate messaging system. For this situation all messages
get rewritten to a common e-mail address. For example, Fabrikam
purchases Contoso, and because they should use the Fabrikam e-mail
address, they rewrite every @contoso.com address into @fabrikam.com.
Note: Address
rewriting will replace the e-mail addresses of messages. You have to
make sure that the properties of the recipient mailboxes include the
replaced e-mail address in their proxy addresses; otherwise a reply
will receive an NDR.
In some situations—for
example, signed, encrypted, or rights-protected messages—you cannot
change an e-mail address because that would, for example, make a signed
message invalid. The address rewriting agent thus will not change the message in any way as it would make the message unreadable.
Note: Using address rewriting can break your federating calendaring requests because the domain name is changed. If you use address rewriting and you want to implement federated sharing,
ensure that all domains involved in the address rewriting are defined
in your federated organization identifier.
Address rewriting is
configured using the Exchange Management Shell (EMS); you cannot
configure address rewriting in the Exchange Management Console.
You configure address rewriting using the New-AddressRewriteEnty cmdlet. You can configure address rewriting in the following ways:
Rewrite a single e-mail address, one domain, or a domain including all its subdomains.
Rewrite addresses on either inbound and outbound messages or just outbound messages.
Let's go back to our scenario
where Fabrikam buys Contoso. Contoso's Exchange organization is
currently not your responsibility, but every message they sent to the
Internet is transported over Fabrikam's Edge
Transport servers. You want to make sure that every outbound
Contoso.com e-mail address is replaced with Fabrikam.com. So first you
have to make sure that every Contoso recipient exists in the Fabrikam
Exchange organization with an e-mail address that matches both their
Contoso.com and the Fabrikam.com address. Additionally there must be a
Send connector to forward messages for Contoso users (addressed with
their Fabrikam.com mail address) to the Contoso Exchange organization.
If that's guaranteed, you can use the following cmdlet on your Edge Transport servers to enable address rewriting:
New-AddressRewriteEntry -Name "Contoso to Fabrikam" -InternalAddress Contoso.com
-ExternalAddress Fabrikam.com -OutboundOnly $true
